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SUMMARY 



Problem 

The Office of the Manager of the National Communication System 
(NCS) requires timely accurate information about communications re- 
sources during national disasters. This led to the development of a 
pair of decision support systems (DSS) for the National Emergency 
Management teams. These systems are the Emergency Preparedness 
Management Information System (EPMIS) and the Fly-Away Management 
System (FAMIS). 

This report covers the FAMIS system. FAMIS' currently exists as a 
prototype written in BASIC and implemented on portable Otrona micro- 
computers. The prototype is in an early stage of development. It has 
been useful for defining the final system. 

Now that the concept has been developed, it is time to move beyond 
the prototype stage. NCS must start a disciplined development effort. 
The remainder of this report deals with the definition of the problem 
and the process of setting up a development effort. 

Objective 

There were several objectives in this project. They were: 

1. Determine how to speed up the current FAMIS prototype. 

2. Determine how to structure and integrate EPMIS and FAMIS. 

3. Suggest approaches to long term FAMIS structure and design. 

4. Suggest administrative approaches for EPMIS/FAMIS. 

Approach 

In performing this work, I did the following: 

1. Analyzed FAMIS code. 

2. Rewrote portions of FAMIS code. 
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3. 
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Reviewed reports from NCS and Booz, Allen and Hamilton on 
the EPMIS/FAMIS system. 

4. Reviewed related DSS and system development literature. 

5. Reviewed computer software for useful packages. 

Results and Conclusions 

The work on the EPMIS/FAMIS system has reached a critical point. 
Management needs to establish a clear set of goals and priorities for the 
system development to succeed. My specific recommendations are: 

1. Establish a set of goals for the system. 

2. Design decision modules to implement these goals. 

3. Design a database to support the decision modules. 

4. Give contractors more guidance in pursuit of these goals. 
Booz, Allen and Hamilton have produced little useful in the 
EPMIS database design. Until they do, all development on both 
EPMIS and FAMIS is effectively blocked. 

5. Improve the FAMIS prototype for short term demonstration pur- 
poses in the following ways. 

a) Compile the FAMIS prototype. 

b) Move to a hard disk environment. 

c) Use on faster micro. 

d) Speed up the graphics. 

e) Use as a test bed for future enhancements. 

6. Design an administrative support structure for FAMIS. 

a) Define goals for integrated EPMIS/FAMIS. 

b) Develop administrative procedures for data management. 



c) Try to achieve high degree of interoperability between 
EPMIS and FAMIS. 



d) Plan to operate in a permanent prototyping mode. This 
means that a capable systems team should be able to make 
fast changes to the system without going through a whole 
systems development cycle. 

e) Develop a software team used to quick response and devel- 
opment. 

7. Implement the following hardware and software steps. 

a) Choose compatible software for EPMIS/FAMIS. 

b) Design for interoperability between EPMIS VAX system and 
FAMIS micro system. 

c) The best system choices are the C language for custom ap- 
plications, SQL for database and FOCUS for unstructured 
queries into the database. 

d) Replace Otrona with hard disk 80286 based portable. 

e) Plan to replace the replacement in a few years. 

f) Encrypt the FAMIS database. 

g) Watch developments in laser disks. 

Future Research Considerations 

Much needs to be done to make EPMIS/FAMIS a truly useful system. 
We do not have the resources needed to do everything required. That 
will take years. I have outlined the steps NPS can accomplish in the 
next year. 

1. Design a data dictionary structure for capturing data about the 
database. 

2. Produce an initial FAMIS database design. 

3. Produce a compiled C version of the current FAMIS file based 
prototype. 

4. Produce a "proof of concept" prototype of a database oriented 
set of FAMIS routines using an 80286 based computer, a hard 
disk system, C language and SQL database management system. 



IV 



5. Produce a "proof 0 f concept" prototype of high resolution 
graphics routines for improving FAMIS geodata support. 

6. Produce a database system that is capable of passing NUDET 
geodata to FAMIS in latitude and longitude format from input in 
location, direction and offset format. 



v 



CONTENTS 



SUMMARY // 

page 

7. INTRODUCTION 7 

2. CURRENT FAMIS CAPABILITIES 2 

Analysis Steps Taken . 5 

Conclusions 6 

3. DEFINING DECISION MODULES 8 

4. CHOOSING SOFTWARE 70 

5. CONCLUSIONS 18 

REFERENCES 25 



VI 



7 



INTRODUCTION 



The Office of the Manager of the National Communication System 
(NCS) requires timely accurate information about communications re- 
sources during national disasters. This led to the realization that an 
automated decision support system (DSS) could be useful to the National 
Emergency Management teams. These teams will play control the moni- 
toring and resolution of claims on the system. 

Meeting these requirements is the task of the integrated emergency 
preparedness management information system (EPMIS) and the fly-away 
management system (FAMIS). They are an integral part of the national 
telecommunications management system. This system will be an inte- 
grated system of mainframe and microcomputers . The mainframe com- 
puters contain the information necessary to reconstruct the national 
communication system. Analysts in the field use microcomputers to pro- 
cess the information that they will need in the reconstruction of the 
system . 

The system is still in the early design stages. This report covers 

mostly the FAMIS portion of the system. Of necessity, however, it also 
includes material on the integration with EPMIS. The FAMIS system 

currently exists as a prototype. This prototype was written in BASIC 
and implemented on portable Otrona microcomputers . The present sys- 
tem is a decision support system of the file drawer variety. It is used 
solely for information retrieval. Eventually, information analysis and 
expert system capabilities will be necessary. 

The FAMIS prototype is obviously in an early stage of development. 
Many enhancements are needed to make it a feasible system for produc- 
tion use. The prototype has been a useful learning tool for defining 
the final system. The prototype has generated interest in the project. 

Now that the concept has been approved it is time to move beyond 
the prototype stage. A disciplined development effort is required. The 
remainder of this report deals with the definition of the problem and 
the process of setting up a disciplined development effort. 
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CURRENT FAMIS CAPABILITIES 



The FAMIS microcomputer systems is a 2,700 line BASIC program. 
It is written in GW-BASIC, an MS-DOS dialect. This is because the 
system uses the Otrona portable microcomputer. GW-BASIC is similar 
to IBM’s advanced BASIC. Judging from the dates on the disks we re- 
ceived, development stopped in late 1983 or early 1984. Little docu- 
mentation is available beyond one document from NCS [National Commu- 
nications System, August 1983] which listed the menus and brief 
descriptions of their functions. 

The best way to examine the system is to look at the menus. These 
show the functions and what they do. The main menu for the system is 
below 



FAMIS Main Menu 



1 . P . O . C . Lists 

2. Emergency Activation Procedures 

3. Network Status Monitoring 

4. Damage Assessment 

5. Resolution of Claim 

6. Zooming 

7. Word Processing (WordStar) 

8. NSC Processing Module 
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Item 1 is point of contact list. This option allows the user to get 
the primary point of contact for various government and private agen- 
cies. The program returns the point of contact name, address, phone 
number, and alternative means of contact. There is currently no formal 
means of updating these point of contact lists. It is possible to update 
the list using the word processing selection later in the menu. To do 
this effectively the user would have to know a lot about the data struc- 
tures employed by the system. Even then it would be a risky process. 
There is too much chance that a novice would damage the database and 
render the system inoperable. 

Item 2 is emergency activation procedures. This option displays in- 
structions for activating the emergency procedure. It includes informa- 
tion on a conditions required before activation of the NCS. This option 
is a reference manual of procedures for the field analyst using FAMIS. 

Item 3 is network status monitoring. Selection of this item gener- 
ates graphic views of the status of government and commercial communi- 
cations networks. This can be done at either the national or regional 
level. Map displays show connectivity and current damage status of 
major switching centers. 

Item 4 is damage assessment. This selection allows the user to up- 
date the current network status data. The user may add information 
on observed or predicted damage to network switching centers or com- 
munication nodes. 

Item 5 is resolution of claim. This option has not yet been imple- 
mented. Presumably it will allow the user to request that a particular 
node or communications link be reestablished or modified. This request 
is called a claim and all claims are held by the system and are available 
to be listed for the user. A major task of the NCS is to assign a prior- 
ity to claims on the system. 

Item 6 is zooming. This feature was not provided in the material we 
received from NCS. 

Item 7 is word processing. The word processing is not built into 
the FAMIS system. Word processing is implemented by calling an ex- 
ternal word processor. Here the system calls WordStar. This feature 
will not work on the IBM advanced BASIC version 2.0. It requires the 
SHELL command which does not exist in IBM's advanced BASIC 2.0. 
This feature is in IBM’s BASIC 3.0. With this selection, a user can 
edit external files. It is used to modify the database or compose mes- 
sages . 
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The final menu item is the NSC processing module. Its purpose was 
not explained in the documentation we received. Presumably it gives 
contacts on the National Security Council. Perhaps the data is too sen- 
sitive for general circulation. 

Using a prototype has enabled NCS to field a version of the FAMIS 
system faster than using a traditional systems life cycle. The proto- 
type is similar to the final product. It has been useful to generate in- 
terest in the project. 

Nevertheless, the prototype has many problems. Its usefulness is 
at an end. The system was written in BASIC, an interpreted language. 
This allowed for fast development because compiling and link editing 
were unnecessary. This is the only good news about BASIC. Every- 
thing else is bad news. Because it is an interpreted language, it is 
slow. Non-prog rammers designed BASIC for use by non-programmers. 
It is presumably easy to learn. That may be true but it is also hard to 
use. The language is unstructured . Programs in BASIC are extremely 
difficult to maintain. Data handling is slow and clumsy. It does not 
lend itself to sophisticated file and data base techniques common to 
modern languages like C or PASCAL. 

As is usual in a prototype, there are many errors in the system. 
There are occasional unexplained abends. Many of the features present 
in the menus are not yet implemented. Some of the features present 
are incorrect. This is true in the the map oriented systems. In the 
damage assessment modules, map displays do not work properly. A 
rectangular damage area fails to plot properly. The code needs to be 
thoroughly rewritten and tested. I suspect the map uses a conical pro- 
jection and the rectangular damage areas use a Mercator projection. 
Clearly the system needs a more sophisticated geodata display. 

There are additional problems with this system. It is largely undo- 
cumented. The only documentation is a listing of screen displays and 
menus. The program itself is mostly uncommented. This may be nec- 
essary since BASIC is an interpreted language. By using few com- 
ments, the interpreter does not waste time processing comments. But, 
it makes the resulting product nearly impossible to maintain. 

Because of the limited length of BASIC variable names, it is difficult 
to design data names for mnemonic value. This makes it hard for main- 
tenance programmers to determine what is going on with data handling. 
Finally, the program uses several questionable practices to accomplish 
its ends. One example is the menu item that allows the user to exit to 
WordStar. This gives the user free range to change values in data files 
and fields. The system is complicated enough for an experienced pro- 
grammer or data analyst. One would not want to turn an inexperienced 
user loose on these data files. The result can only be disaster. 
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2.1 



ANALYSIS STEPS TAKEN 



In analyzing this system I had two major goals in mind. The first 
was to speed up the existing system for demo purposes. The second 
goal was to analyze the system to determine the features or changes 
needed for future revisions. 

I took several steps to see if I could speed it up. They included: 

1. Rewriting portions of the system. 

2. Moving the system to a hard disk. 

3. Developing techniques to speed up the graphics. 

4. Compiling a portion of the code. 

5. Running a compiled system using an 80186 based accelerator 
board . 

6. Rewriting a portion of the code in C. 

7. I n vesitgating data base management systems for both EPMIS and 
FAMIS. 

These approaches offered some help. Moving the system to a hard 
disk was useful. The major benefit was that the user no longer had to 
worry about swapping floppy disks. The necessary files were automati- 
cally loaded off the hard disk. There was a slight increase in speed 
(perhaps by a factor of 2). But, the system was so slow to begin with 
that this could hardly be called major. Compiling the system using a 
Microsoft BASIC compiler helped much more. Unfortunately the Micro- 
soft BASIC compiler is limited to 64K. I could not compile the complete 
system. I was able to compile the main driver module and the damage 
assessment module. The damage assesment module contains the most 
detailed graphics. I figured that this is an important routine that com- 
pilation should speed up. The compiled version of the code runs some- 
where between 5 and 10 times faster than the floppy disk version. 
This is good but still not acceptable. 

Next I tried to speed up the graphics. The NCS programs perform 
graphics a point at a time using the BASIC graphics commands. This 
means that it may take as much as a minute to generate a map of the 
United States and communications facilities. It may not sound like much 
but it is painfully slow sitting in front of a computer. Even in inter- 
preted BASIC it is possible to achieve speeds much faster than this. 
This is done by using the BSAVE and BLOAD commands. This makes it 
possible to generate a screen in about three seconds. 
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The same screen graphics capabilities are available in other lan- 
guages, Using C, it is possible to generate screens in about a tenth of 
a second. The disadvantage of this approach is that the entire screen 
must be saved on a file. A graphics screen requires 16K of storage 
space. This might be a problem on a floppy disk based system. On a 
hard disk system it is no problem at all. Since hard disk systems are 
cheap, future designs for FAMIS should assume hard disk or laser disk 
storage. There is no point in locking into the older technology. 

Running the compiled version of FAMIS using an 80186 based accel- 
erator board produced dramatic increases in speed. Menus and graph- 
ics are generated quickly. The FAMIS system makes heavy demands on 
a microcomputer. Future versions of this system should use faster chips 
than the old 8088 technology. The same comment applies here as applied 
to disks. Design the system using that best technology available. 

Rewriting a portion of the code in C gave the biggest increase in 
speed. A structured language like C or PASCAL is simply better suited 
to this kind of problem. In addition, C offers much greater availability 
of sophisticated program libraries than BASIC. These libraries have 
functions for screen formatting, graphics and data base. 

The final step was the investigation of data base management sys- 
tems (DBMS). In the prototype, a change to a data structure requires 
a change to the program. The major benefit of a DBMS is that it allows 
program-data independence. One can change file structures without 
reprogramming. There are several DBMS that are interoperable on minis 
and micros. Unfortunately, none of them work with BASIC. 



2.2 CONCLUSIONS 

For the short run, there are several things that can be done to 
make the prototype more useful. They are: 

1 . Compile it. 

2. Move its programs and data to a hard disk. 

3. Run it on a faster processor. 

4. Use stored graphics geodata. 

This means the Otrona microcomputers have outlived their usefulness. 
A more useful computer would be a Compaq with a hard disk. Unfortu- 
nately, this computer will be be obsolete within a year or two. They 
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will be replaced by portable systems using faster chips, larger hard 
disks, and laser disks. All this is normal in such fast moving technol- 
ogy. 

Running the prototype on a more powerful machine would merely be 
a cosmetic change. It is the technical eqivalent of putting a Model T 
engine in a Porsche body. We can make the prototype run faster, but 
it cannot be easily expanded or modified. BASIC has too many faults 
for a production version of FAMIS. We should take our lessons from 
the BASIC prototype and move on. 

The drivers for the screens and graphics should use a compiler lan- 
guage. The data structure should be implemented on a compatible data 
base management system (DBMS). The system should use a language 
and data base system that is interoperable with the mainframe system. 
This would allow a system that is more powerful, more flexible, and 
more reliable than the current prototype. 
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DEFINING DECISION MODULES 



The steps required are: 

1. Review and if necessary, revise the goals of the combined 
EPMIS/FAMIS systems. 

2. Design the decision modules needed to support the goals. 

3. Identify the data needed to support the decision modules. 

4. Select the hardware and software configuration needed to sup- 
port the system. 

5. Begin work on the system using a disciplined prototyping ap- 
proach rather than the full systems life cycle approach. 

The first step should be to identify the decision and data components of 
the decision support system (DSS). The most important investment in 
the project so far is not the BASIC prototype program. It is the data 
and the sources of data that are used by the prototype. If the manag- 
ers of' the project do not take steps soon to create a formal data struc- 
ture and data gathering system, this intellectual capital will be lost. 

An important step in this process is data design. It is necessary to 
identify the data needed to support decisions made by the system. It 
is also necessary to develop models and decision aids needed by the an- 
alysts to reconstruct the communications system. Once we define the 
data structure, we need to design the data distribution. This also in- 
cludes designing networks for communications between the center and 
field analysts. 

The issue of hardware and software presents a dilemma for the 
EPMIS/FAMIS system design. Typically, hardware and software selection 
are done after the data design and decision design components of the 
system are completed. But, hardware and software for this type of 
DSS is changing rapidly. Any decisions made now are likely to be ob- 
solete in a short time. The decision requirements will change constant- 
ly as well. Managers must realize that this system will never be com- 
plete. It will always be evolving. 
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There are many developments coming up soon that will impact 
EPMIS/FAMIS design. Examples include high quality laser disc systems, 
faster microcomputers, better graphics, and expert systems. The most 
important thing is to create a flexible logical design for the system. We 
can find hardware and software to carry out the logical design. If we 
concentrate first on hardware and software design then the logical de- 
sign issues are likely to be lost. 

It is necessary to set up an administrative infrastructure to support 
the operation. I would place the offices of data administrator and of 
systems administrator at the top of the list. The data administrator acts 
as the custodian and keeper of the data in the system. Much of the 
data is highly volatile. Information is included on points of contact and 
procedures. These change rapidly and is the responsibility of the data 
administrator to track these changes and enter them into the system. 

This, means that NCS must create a data collection system. It is 
necessary to identify the sources of data and to keep the data current. 
One might use techniques such as a computerized tickler file to send 
out letters to monitor changes in the system. The data in the proto- 
type is out of date. This is not surprising since it is about two years 

old. If 20% of the points of contact change every year (probably low), 

the data has a three year half-life. 

The responsiblity of the data administrator is to track this data and 
see that it is current. The responsibility of the systems administrator 
is to keep abreast of technical developments that affect the system. 
This responsibility includes monitoring the design of both the EPMIS 
and FAMIS sides of the system. This means tracking technical develop- 
ments that would affect either system. The systems administrator is in 
charge of the configuration and development of the system. 

The hardware and software in the systems must be easy to maintain 
and technically current. The software and data structures should be 

be usable across machine lines. This is not easy, but micros and minis 

are evolving so that it is possible. As microcomputers become more so- 
phisticated, they share many systems with their larger cousins. A de- 
sign goal of the EPMIS/FAMIS system should be to use the same pro- 
grams and data structures on both systems. 
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CHOOSING SOFTWARE 



The hardware and software decisions must support the overall sys- 
tem goals. The EPMIS/FAMIS managers must not fall into the trap of 
the traditional systems development life cycle. The life cycle model 
views a computer system as a solution to a problem. We encounter a 
problem. We analyze it. We design a system to solve it. Finally, we 
implement that system on a computer. 

This may work well enough when working with simple, bounded 
problems. These are not the problems that the EPMIS/FAMIS system is 
intended to solve. These systems are decision aids for an unstructured 
enviroment. System requirements will continue to evolve over the life 
of the system. If we try to state them fully at the beginning, we will 

never finish. Daniel McCracken and Michael Jackson [1982, p. 30] 

stated the problem best. 

The life cycle concept perpetuates our failures so far, as 
an industry, to build an effective bridge across the com- 
munications gap between end-users and systems an- 
alysts. In many ways it constrains future thinking to fit 
the mold created in response to failures of the past. 

In this system, we should make our software decisions first. Then, 
we can find hardware on which to implement this software. The soft- 
ware goals should be: 

1. The software should be portable across machine lines. It 

should be useable on both micros and minis. 

2. The software should be reasonably fast. The user should not 
have to wait forever for text or graphics output. 
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3. The software should support a DBMS. We must design our ap- 
plications so that data and programs are independent. This is 
a major goal of a DBMS. If programs and data are not indepen- 
dent, maintenance and enhancement is almost impossible. 

4. The language chosen for the software should be a structured 
language suitable for modern programming practices. 

5. The software should support queries by untrained users. 

This is a formidable set of requirements . The language chosen must 
allow for fast development. It will have to support sophisticated appli- 
cations like graphics and data base. At the same time it will have to 
support untrained users. 

To choose a language, we must examine the choices available on 
both microcomputers and minicomputers. The first language we will ex- 
amine is BASIC. BASIC stand for Beginners All-Purpose Symbolic In- 
struction Code. It was invented at Dartmouth in 1964 and it evolved 
continuously since then. It is widely available on many classes of com- 
puters. The advantages and disadvantages of BASIC are listed below. 



BASIC - Advantages 

1. BASIC is somewhat standardized. 

The implementations available on microcomputers and minicom- 
puters have many features in common. Programmers could 
move from one environment to the other without having to rel- 
earn the language. 

2. BASIC is easy to learn. 

Most people can write simple programs in a few hours. In a 
few weeks they are able to do complicated programs. 

3. BASIC is an interpreted language. 

This means that it is fast to write and change programs. 

4. Compilers are available for BASIC. 

The interpreted programs can be translated into object modules 
which run much faster than the interpreted version. 

5. Programmers in BASIC are widely available. 

Most programmers know BASIC. 
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BAS I C - Disadvantages 



1. BASIC is slow to execute. 

A large program in interpreted BASIC can be painfully slow. 
Even compiled BASIC is slower than compiled versions of more 
sophisticated languages. 

2. BASIC is unstructured. 

It does not support constructs like the I F-THEN-ELSE, the 
DO-WHILE or the PERFORM-UNTI L. Some versions of BASIC 
have these constructs. But, these versions of BASIC sacrifice 
portability. Because it is unstructured, BASIC encourages the 
worst possible programming habits. Programs written in BASIC 
are nearly impossible to maintain. 

3. BASIC is hard to use. 

This sounds paradoxical since an advantage of BASIC is that it 
is easy to learn. Easy to learn does not mean easy to use. 
Programs written in BASIC quickly become unmanageable. A 
programmer quickly loses control of the program. When the 
size of a program goes much above a hundred lines, there is 
little hope of cleaning it up, 

4. BASIC's data handling features are poor. 

Beginning students seldom deal with large amounts of data. 
This may not be a handicap for teaching, but it is a handicap 
for use with the EPMIS/FAMIS systems. BASIC's lack of a re- 
cord structure makes it extremely difficult- to handle data. 

5. BASIC does not support data base management systems. 

It is either difficult or impossible to link from BASIC to DBMS 
available on the same machines. 

The next choice of language is COBOL. COBOL stands for Common 
Business Oriented Language. It was defined by a joint committee of 
users and Department of Defense in 1959. COBOL is widely used for 
data processing in both government and the private sector. The ad- 
vantages and disadvantages of COBOL are listed below. 



COBOL- Advantages 

1. COBOL is a standardized language. 

The versions available on many different systems are similar. 

2. COBOL is a data processing language. 
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It is ideally suited for handling fields and records. It has a 
wide variety of editing functions built in. 

3. There are many programmers available who know COBOL. 

It is not as widespread as BASIC, but it is the language of 
choice in the commercial programming world. It is not difficult 
to find programmers familiar with this language. 



COBOL- Disadvantages 

1. COBOL is an old fashioned language. 

It does not support some of the modern control structures. It 
is also difficult to break a COBOL program up into modules or 
subroutines . 

2. COBOL does not support data base well. 

It handles data well in a file processing environment. The 
links to a data base may or may not be available. 

3. COBOL is slow. 

4. COBOL has a poor to non-existent mathematics capability. 

If your problems require any numeric processing, COBOL is a 
poor choice. 

5. COBOL is intended for batch processing operations. 

It supports screen -oriented on-line operations poorly. 

FORTRAN is the next language to consider. FORTRAN stands for 
Formula Translator. It is an old language, developed at IBM in the 
1950's. It is since become the standard language for scientific process- 
ing. It is available on minicomputers, mainframes and micros. The var- 
ious versions of FORTRAN are usually quite compatible. It is an easy 
language to transfer across machines. In spite of this, FORTRAN is 
uncommon on microcomputers. The advantages and disadvantages of 
FORTRAN are summarized below. 



FORT RAN -Ad vantages 

1. FORTRAN is a standardized language that moves easily from 
machine to machine. 

2. There are many programmers available for FORTRAN. 

Until recently, FORTRAN was the first language that most peo- 
ple learned. It is since been supplanted by BASIC. 
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3. FORTRAN has excellent mathematical processing capabilities. 
There are many mathematical libraries available for FORTRAN. 

4. FORTRAN is well suited to minicomputers and mainframes. 



FORTRAN -Disadvantages 

1. FORTRAN is an old fashioned language. 

The older versions of it are the most transportable, and they 
do not support structured programming constructs. 

2. FORTRAN has poor data handling features. 

It does not support record structures at all. String manipula- 
tion in FORTRAN can be maddening. 

3. FORTRAN usually does not support interface to DBMS. 

4. FORTRAN, like COBOL, is not well suited for screen oriented 
operations . 

The next language, C, was developed at the Bell Telephone Labora- 
tories in the late 1960's and early 1970's. It is a simple, yet powerful, 
structured programming language. It allows users to perform systems 
programming activities without having to resort to assembly language. 
The advantages and disadvantages of C are summarized below. 



C - Advantages 

1. The various versions of C are standardized and stable. 

The language was invented to facilitate transfer of programs 
from one type of machine to another. It performs this function 
well . 

2. C is a structured language. 

It has the full range of structured constructs. 

3. C has powerful features. 

These range from record oriented constructs at the top level 
down to constructs that allow you to manipulate bits and bytes. 

4. There is a wide choice of support libraries available for C. 
These include libraries for mathematics, graphics, screen han- 
dling and language extensions. 



14 



5. C is the language of choice on microcomputers and minicomput- 
ers . 

Many of the systems available on microcomputers are written in 
C. Much the same is true on minicomputers. On Digital 
Equipment Corporation's PDP-11 and VAX systems, C is the 
language used to implement the UNIX operating system. 

6. C offers interfaces to DBMS. 

Many of the DBMS available on microcomputers are written in 
C. 

7. Interpreters are available for C. 



C-Disadvantages 

1. C programmers are hard to find. 

A recent issue of the Government Computer News noted that C 
programmers in the Washington, D.C. area frequently receive 
five figure raises when changing jobs. This is because C is 
the language of choice for implementing military command and 
control systems and sophisticated systems software. Program- 
mers of this type are in demand. 

2. C is not a language for beginners. 

It requires sophistication and skill in programming. 

The next language is PASCAL. PASCAL was developed by Nicholas 
Wirth in Zurich, Switzerland in the 1970’s. It is named after Blaise 
Pascal, the French mathematician. PASCAL is intended to be an in- 
structional language. It encourages structured programming habits. 
The language has grown in popularity since its invention. It now is 
the language of choice for beginning instruction in Computer Science. 
It has replaced BASIC for serious computing instruction. It is widely 
popular on microcomputers and minicomputers. The advantages and 
disadvantages of PASCAL are summarized below. 

PASCAL- Advantages 

1. PASCAL is somewhat standardized. It is widely available on 
mainframes, minicomputers and microcomputers. The versions 
on different machines differ somewhat. This can be annoying 
but, generally, it is not serious. 

2. PASCAL is a structured language and offers a wide variety of 
powerful features. 
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3. The language is widely available on mini and microcomputers. 

4. PASCAL programmers are readily available. 

Most computer science students from good programs have done 
their work in PASCAL. 



PASCAL- Disadvantages 

1. PASCAL has a narrower range of support packages than is 
available in C. 

2. There are usually no special interfaces to DBMS in PASCAL, 
although one could probably modify C interface techniques to 
work. 

3. There are no PASCAL interpreters available. 

This may be less of a problem than it seems. The most popu- 
lar version of PASCAL on microcomputers is Borland’s Turbo- 
PASCAL. Turbo is a compiler but it operates fast enough that 
it is as easy to use as an interpreter. 

4. PASCAL is slower than C because of the strong typing of vari- 
ables used to support the instructional mission of the language. 

5. The versions of PASCAL that are available on microcomputers 
do not support the large memory models. 

They think of the machine as a 64K machine and cannot use the 
1 megabyte and larger memories on newer machines. 

The next language is FOCUS. This is a language developed in the 
1970’s by a company called Information Builders Inc. It one of a class 
of languages called Fourth Generation Languages (4GL) or Higher Order 
Languages (HOL) [Harel and McLean, 1985; Martin, 1982]. These are 
integrated languages that pre-dated packages like Symphony and 
Framework by 10 to 15 years. These languages allow novices to use 
integrated data base management systems, spreadsheet modeling, statis- 
tical packages and graphics. 

Recently, the vendors of these languages have begun to offer their 
products on microcomputers as well as mainframe computers. One de- 
sign goal in their product is to facilitate data and program transfer 
from microcomputers to mainframe and minicomputers. They offer the 
same version of their languages in both environments. The advantages 
and disadvantages of FOCUS are summarized below. 



FOCUS - Advantages 
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1. FOCUS is an integrated system available on both micro and 

minicomputers . 

2. FOCUS is easy to learn. 

3. FOCUS supports ad hoc queries into the data base. 

4. - FOCUS supports a powerful data processing programming capa- 

bility. 

FOCUS- Disadvantages 

1. The system is large and clumsy. On a microcomputer it re- 
quires 512K of memory and 3 and a half megabytes of the hard 

disk. 

2. FOCUS is slow. 

3. FOCUS is business data processing oriented. 

The geodata routines required by the EPMIS and FAMIS will 

have to be programmed in C. 
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CONCLUSIONS 



Work on the EPMIS/FAMIS system has reached a critical point. NCS 
has created structures to gather data about the communications sys- 
tems. It has made a start on a system to store this data in computer 
readable form. Much remains to be done, however. Management needs 
to establish a clear set of goals and priorities for the system develop- 
ment to succeed, Currently, the goals of the project are unclear. The 
computer systems supporting the project reflect this. EPMIS/FAMIS 
system cannot succeed until NCS has a clear vision of its mission. It is 
impossible to design a decision support system without a clear idea of 
the decisions supported. 

In one sense, this may never be possible. EPMIS and FAMIS gather 
information and support decisions in an unstructu red , chaotic environ- 
ment. There can never be a finished system. The EPMIS/FAMIS project 
will always have to operate in a prototyping mode. 

NCS needs to assemble a flexible programming team to implement this 
system. This system team must also be highly competent. They should 
be able to design implement new programming and data structures 
quickly. In the conditions under which EPMIS/FAMIS will operate, 
there will be no time for a complete system development life cycle. A 
primary design goal must be flexibility. The specific recommendations 
for the EPMIS/FAMIS system follow. 

First, establish specific goals for the system. The EPMIS/FAMIS 
system as it now stands is simply a file drawer system. It stores in- 
formation about the current status of the communications system. 
FAMIS operators can enter status changes to that system. The system 
needs to be able to do more than this. 

The NCS managers must develop means for setting priorities and re- 
solving claims on the communications system. EPMIS/FAMIS should offer 
support for these decisions. This issue is politically sensitive, but un- 
til it is resolved, NCS cannot be effective in an actual crisis situation. 
NCS must have well defined goals to implement an effective decision 
support system. 
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Next, it is necessary to design decision modules to implement the 
goals. Until the goals are clear, the nature of the decision modules will 
not be clear either. The simple file drawer decision support system has 
its uses. But, more sophisticated decision support modules are needed. 
Examples might include mathematical programming algorithms to help 
reestablish connectivity. Another possibility would be queueing or sim- 

ulation models to help predict actual load on the system. Expert system 
decision modules would be of immense help in codifying the rules used 
to resolve claims on the communications system. 

Finally, begin design of a database to support the decision modules. 
The current system is not a database. It is a file oriented system. 
File oriented systems were common in th6 third generation computer 
languages. They caused the structure of the data to be hopelessly im- 
bedded in programs. If the data structure is changed, then programs 
must be changed as well. As the system grows, this becomes an in- 
creasingly complex task. The result is that once the system has 
reached a certain size, it is too much trouble to change it. The system 
can no longer expand. Given the goals of the EPMIS/FAMIS system, this 
would be disaster. 

The solution is a database management system. The best choice 
would be a relational database management system. Relational database 
is the newest technology and the easiest to work with. Database gives 
you program-data independence. It allows expansion of the database to 
take place independently of the programs. 

Work on data design should begin immediately. Data design can 
take place before choosing a database management system. Eventually a 
data design must be implemented on a specific database management 
system. Design issues are independent of the database management 
system (for relational systems), so the specific relational system chosen 
is irrelevant. The first step in data design is to establish a data dic- 
tionary structure to capture facts about the data base. Facts include 
field names, field lengths, field types and sources of data. 

The design process should use the current FAMIS files. These files 
are the most valuable part of the FAMIS prototype. They serve as a 
guide in moving from a prototype system to a production system. Be- 
gin immediately to isolate the data items, to assign them reasonable field 
names, and to begin the data dictionary building. 

Once the data dictionary system is established, we can begin to as- 
sign these fields to files or relations. The relations should be in third 
normal form. This allows for easy modification of the data later. Once 
the data structure has been laid down, NCS can set up an administra- 
tive structure for data capture. The data that makes up the FAMIS 
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system has a short half life. This half life is almost certainly less than 
three years There must be a means of capturing information about 
changes to the system. 

The data dictionary system will serve as a basis for tracking chang- 
es. The process of tracking changes should be automated to the great- 
est extent possible. Using the FAMIS data dictionary system, one could 
set up a computerized letter generator. This system could periodically 
request updated information from the relevant agencies. The 

EPMIS/FAMIS system is only as good as the data making it up. 

As part of this project, the material from Booz, Allen and Hamilton 
was reviewed. Booz, Allen and Hamilton has produced little useful 
material for EPMIS/FAMIS so far. Their reports are mostly rehashes of 
standard material. They are only marginally useful in the design of the 
EPMIS/FAMIS system. One report is largely a program listing of the 
FAMIS prototype. It has a few comments about the program, but it of- 
fers nothing new or useful. 

Two other reports are rewrites of standard system analysis texts 
(the book by Powers, Adams and Mills, 1984 comes to mind as a possi- 
ble source, but many sources are possible). The material has been re- 
written to apply to the NCS' situation. There is nothing wrong with 
using the best available sources in a report. The only problem with 
this material is that it is too superficial and too general. Booz, Allen 
and Hamilton should have provided a detailed analysis of the NCS situ- 
ation . 

My hypothesis is that Booz, Allen and Hamilton have not received 
sufficient guidance. The project needs to be better defined. What they 
have produced is a reflection of the current state of the EPMIS/FAMIS 
system. They seem to feel that the FAMIS system could remain as it 
is, written in BASIC and implemented on the Otrona microcomputers. 
Considering the needs of the FAMIS system, this is a strange recom- 
mendation. There are obviously problems with FAMIS. Booz, Allen and 
Hamilton should be the first to point them out. I doubt that they have 
assigned their first team to this project. Their work looks like a term 
paper in an MBA Systems Analysis class. To use high-priced consult- 
ing talent, one must provide well-defined tasks with explicit delivera- 
bles . 

The next recommendations deal with improvement of the FAMIS pro- 
totype. The prototype is near the end of its life cycle. It is useful in 
the short term for demonstration and training, but it is not a produc- 
tion system. Several steps can be taken to enhance its usefulness. 
These include: 
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1. Compile the system. 

It is possible to speed the system up by a factor of between 10 
and 20 by compiling it. The compiler used should be able to 
use all available memory. Such compilers include the new Micro- 
soft 3.0 version of BASIC or an outside compiler like the Bet- 
ter BASIC compiler. 

2. Move the system to a hard disk. 

The current system uses floppy disks. It is as much a test of 
the manual dexterity of the operator as anything else. The 
continual changing of floppy disks is an annoyance. We have 
put the system on a hard disk at the Naval Postgraduate 
School. The move was simple. All that was required was mod- 
ification of the drive reference on open commands. 

3. Implement the system on a faster microcomputer. 

An 80186 or an 80286 based machine offers a noticable improve- 
ment in speed. This improvement is even better when a com- 
piled version of the prototype is used. These chips offer 
three to four times the speed of the conventional 8088. The 
80286 or 80386 will probably be the target chip for the eventual 
FAMIS system. One may as well start working with them' now. 

4. Speed up the graphics on the system. 

The graphics on the FAMIS system are painfully slow. They 
are generated a point at a time using the BASIC graphics com- 
mands. Even in interpreted BASIC, it is possible to achieve 
faster speeds than this. One can use the BSAVE or BLOAD 
commands. This means that a graph that requires 20 seconds 
to generate in interpreted BASIC is cut to 3 seconds. If one 
uses machine language, the improvement is even more dramatic. 
The three seconds required by the BASIC commands can be cut 
to one-tenth of a second or less. These techniques require the 
use of 16K of file space for each graphic screen saved. This 
might be a severe limitation on a floppy disk based system. On 
a hard disk system it is not a problem. 

5. Use the prototype system as a test bed for future enhance- 
ments, but ultimately abandon it. 

The prototype has outlived its usefulness and the sooner that 
its lessons can be moved to a more powerful system, the bet- 
ter. 
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The next point concerns the administration of the EPMIS/FAMIS sys- 
tems. Management of the system is at least as important as the software 
and hardware. One needs to develop an administrative support struc- 
ture. This includes both the data and the programming sides of the 
system. For the data side of the system it is necessary to develop an 
information resource management philosophy. 

The first step should be to appoint a database administrator. The 
primary duty of the database administrator is to maintain configuration 
control on the database. It is this person's job to supervise the gen- 
eral structure of the system. The database administrator should oversee 
the management of the data using a data dictionary system. In this ac- 
tivity, the database administrator will have several subordinates. 
These would include clerks and data librarians. It is the function of 
the data librarian to supervise the data at the detail level. This in- 
cludes such duties as making sure that the data is updated in a timely 
fashion . 

The management of the system itself is as important as the manage- 
ment of the data. To give this system the flexibility it needs, NCS will 
have to have a staff of highly competent programmers. These individu- 
als will have to be managed by a knowledgable systems manager. Given 
the way the federal government treats technical personnel, this may be 
an impossible dream. If this is true, then EPMIS/FAMIS is an impossi- 
ble dream as well. It will be the responsibility of th£ system manager 
to maintain configuration control over the EPMIS/FAMIS system. This 
individual will have know the structure of the whole system and be able 
to supervise technical personnel. 

A major goal of the EPMIS/FAMIS system should be a high degree of 
interoperability between the two systems. The EPMIS and FAMIS sys- 
tems should use the same languages. This will reduce the cognitive 
load on the programmers working on the systems. It makes easier to 
transfer programs, data, and storage techniques. A few years ago, this 
would have been impossible. Now many of the same tools used on main- 
frames are being transported to micros. It is increasingly common to 
find the same programming languages used across machine lines. 

The software team should plan to operate in a permanent prototyp- 
ing mode. This will have to be a disciplined prototyping mode rather 
than the loose and sloppy operation that characterized the original 
FAMIS prototype. Programmers will have to learn to document as they 
go, to use structured programming techniques, and to work together as 
a team. This is a common approach among programmers operating in a 
UNIX environment on systems like C. It was obviously not the ap- 
proach used in the original FAMIS prototype. 



- 22 



If the EPMIS/FAMI S system is to provide support in chaotic situ- 
ations, this is the kind of team that is required. The software team will 
have to develop systems quickly. They will have to have a high level of 
technical sophistication. Given the environment in which FAMIS will 
operate, it is not possible to anticipate all demands on the system in 
advance. Those we can anticipate should be built into the system. For 
the others, it will be necessary to respond quickly to changing situ- 
ations as they develop. 

NCS needs to move quickly to lay a hardware and software founda- 
tion for the future. The decisions made now will determine the success 
of the EPMIS/FAMIS system NCS should make some changes to the 
current hardware and software. First is to choose compatible software 
for EPMIS and FAMIS. The current software choices are C and Ingres 
for database for EPMIS, and BASIC and the IBM PC family for FAMIS. 
C is a reasonable language given the sophisticated requirements of this 
system. It operates on both minis and micros. 

The choice of INGRES as a database management system for EPMIS 
also has problems. INGRES is a reasonable database management lan- 
guage, but it does not exist on the PC. The manufacturers of INGRES 
are planning to have a PC version sometime in 1986. Other database 
management systems have this option available now. Another disadvan- 
tage of INGRES is that it is not the direction in which database systems 
are moving. The main database development seems to be headed toward 
SQL. 

There is a move afoot to create an ANSI standard for SQL. This 
language was invented at IBM and is available from several manufactur- 
ers. The best choices would be C for custom applications, SQL for 
database and perhaps FOCUS for applications requiring quick quick de- 
velopment. These packages are available on both mainframes and mic- 
ros . 



Once we have chosen compatible software, the managers of the sys- 
tem must design for interoperability between the VAX and micro system. 
The systems should use the same programs, database management sys- 
tem and data files. This will make for faster, cleaner, and cheaper im- 
plementation efforts . 

A point must be mentioned about the FAMIS database. Strictly 

speaking, none of the data in the database is classified. But, it is not 
something that one would want to fall into unfriendly hands. FAMIS is 
an easy to use blueprint of the U.S. communications system. Moreover, 
in times war or national emergency, information about the status of 
communications systems would be classified. Some steps should be taken 
for protection of the of the FAMIS database. The database should be 
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encrypted. The data provided by a FAMIS operator could be used to 
decrypt the data. 

The final point involves the computers used by FAMIS. The Otronas 
have outlived their usefulness. They were a good decision at the time, 
and now, they should be retired. Their replacement should be a hard 
disk based 80826 system. This would allow for greater storage capaci- 
ties and speeds in the FAMIS system. A high resolution color monitor 
would also be desirable. The managers of the EPMIS/FAMIS system 
should watch developments in laser disks carefully. The geodata dis- 
plays on a current FAMIS system are crude. The laser disks offer the 
possiblility of extremely sophisticated geodata capability. This would 
immeasurably enhance the effectiveness of the FAMIS system. 

This report has outlined many steps that the managers of the 
EPMIS/FAMIS system should consider. The managers need to realize 
that both technical and administrative changes are required. There is 
no technical quick fix for the problems of NCS. A cleaner tighter ad- 
ministration is the first priority. Without that, technical changes would 
be of no benefit. 
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